In recent years, various kinds of communication systems, in particular mobile and/or IP-based (IP: Internet Protocol) communication systems, as well as a multitude of services offered in these systems have been developed.
In such advanced communication systems, such as e.g. Third Generation mobile communication networks currently under development by the Third Generation Partnership Program (3GPP), aspects relating to security and trustworthiness are playing a more and more important role.
Starting from the concept of subscriber certificates, which support services that mobile operators provide and whose provision assists mobile operators, and in consideration of a need for more generic security capabilities, 3GPP standardization work lately concentrated on the evolution of a generic authentication architecture (GAA). As can be gathered from FIG. 1 showing an overview of a generic authentication architecture environment in interrelation with a home subscriber system HSS 14, a user equipment UE 12, and a network entity NE 13, GAA 11 basically consists of three sub-aspects. That is, a generic bootstrapping architecture (GBA) 11b, subscriber certificates 11a, and an authentication proxy (AP) 11c e.g. based on HTTPS (Secure Hypertext Transport Protocol). Thereby, the generic bootstrapping architecture (GBA) also builds a basis for both the other sub-aspects in that GBA offers generic authentication capability for various applications based on a shared secret. Usually, GBA functionality is to bootstrap authentication and key agreement for application security, and it is based on the HTTP Digest AKA (Authentication and Key Agreement) mechanism in accordance with IETF RFC 3310.
In FIG. 2, there is illustrated a network model for generic bootstrapping. A bootstrapping server function BSF 13a and the user equipment UE 12, which are connected via a bidirectional link Ub, mutually authenticate using the AKA protocol, and agree on session keys. These keys are afterwards to be used for a bootstrapping session and to be used between the user equipment 12 and an operator-controlled network application function NAF 13b which is also connected to the user equipment 12 by means of a bidirectional link Ua. After the bootstrapping procedure, which is described in detail below, the user equipment 12 and the network application function 13b can run some application-specific protocol where the authentication of messages will be based on those session keys generated during mutual authentication. Accordingly, GAA/GBA can in general be regarded as a 3-party authentication scenario, wherein the bootstrapping server function 13a is further connected to a home subscriber system HSS 14 maintaining e.g. user security settings (USS).
The reference points (interfaces) between the individual entities in FIG. 2 are denoted by Ub, Ua, Zn, and Zh. The interfaces Zn and Zh are based on Diameter (according to the Diameter Base Protocol which is specified in IETF RFC 3588), the interface Ub is based on a reuse of HTTP Digest AKA messages, and the protocol used on the interface Ua depends on the application to be executed.
The utilization of the generic bootstrapping architecture is divided into two phases. The first phase, i.e. the (generic) bootstrapping procedure as such, is illustrated in FIG. 3, and the second phase, i.e. the generic bootstrapping usage procedure, is illustrated in FIG. 4.
In the bootstrapping procedure according to FIG. 3, the user equipment UE 12 sends an HTTP request towards the bootstrapping server function BSF 13a (step S31). In step S32, the BSF 13a retrieves the user profile and a challenge, i.e. authentication vector (AV), over the Zh interface from the home subscriber system HSS 14. Then, in step S33, the BSF 13a forwards authentication parameters RAND and AUTN to the UE 12 in order to demand the UE 12 to authenticate itself. The UE 12 calculates a message authentication code (MAC) so as to verify the challenge from the authenticated network, as well as calculates session keys CK, IK, and RES. Thus, the session keys CK, IK, and RES are available in both BSF 13a and UE 12. In step S35, the UE 12 sends again a request to the BSF 13a, and the BSF 13a checks in step S36 whether the received parameter is calculated using RES and is equal to the parameter that is similarly calculated using XRES which has been obtained before as a part of the authentication vector from the HSS 14. If these parameters are equal, the UE 12 is authenticated, and the BSF 13a generates a key (“master key”) Ks by concatenating the session keys CK and IK (step S37). The key Ks is then used for securing the Ua interface. In step S38, the BSF 13a sends an OK message including a transaction identifier B-TID and other possible data (such as for example a lifetime of the key Ks) to the UE 12, by means of which the success of the authentication is indicated. By concatenating the session keys CK and IK, the key Ks for securing the Ua interface is then also generated at the UE 12 (step S39). Therewith, a bootstrapping session between the user equipment (client) and the bootstrapping server function has been started successfully.
In FIG. 4, an example procedure using a bootstrapped security association is depicted. After having initiated a bootstrapping session (S40a), the UE 12 can start to communicate with the network application function NAF 13b. Thereby, the master key Ks generated during bootstrapping procedure in the UE 12 and in the BSF 13a is used to derive the NAF-specific key Ks_NAF (step S40b). An application request (step S41) includes the transaction identifier B-TID obtained during bootstrapping, an application-specific dataset denoted by msg, and all credentials being denoted by MAC. In step S42, the NAF 13b requests one or more keys and possibly user profile data corresponding to the information supplied by the UE 12 over the Zn interface from the BSF 13a. Such a request can e.g. be based on the transaction identifier. Between steps S42 and S43, the NAF-specific key Ks_NAF is generated in the BSF entity 13a. In step S43, the BSF 13a responds by supplying the requested key or keys (including Ks_NAF and an application-specific part of the user profile being denoted by Prof) to the NAF 13b, which the NAF 13b uses directly, or with which the NAF 13b derives further keys required to protect the protocol used over the Ua interface towards UE 12, which is an application-specific functionality and not addressed in GAA specifications. Such a derivation is performed in the same way as the UE 12 did beforehand.
Then, the NAF entity 13b stores (step S44) at least the parameters Ks_NAF, Prof, and the lifetime of the key. Afterwards, the NAF 13b continues with the protocol used over the Ua interface by sending an application answer to the UE 12 (step S45).
For further details on the generic bootstrapping architecture, reference is made to the technical specification 3GPP TS 33.220 (version 6.3.0) of December 2004.
In view of the conventional generic authentication architecture and generic bootstrapping architecture described above, there arises the following problem.
In summary, the normal conventional 3GPP GAA behavior is that a client, i.e. a user equipment, bootstraps with the BSF entity using an AKA authentication vector. As a result, so called GAA credentials are obtained which consist of a shared key Ks and a bootstrapping transaction identifier (B-TID). These GAA credentials are further used to derive a server-specific key (Ks_NAF). The NAF-specific keys (i.e. B-TID and Ks_NAF) can then be used between the client UE and the server NAF, such as e.g. as username/password in existing protocols, which case is denoted by the term “generic”.
The conventional bootstrapping procedure requires the client to have a bidirectional connection to the BSF entity, and the subsequent use of the NAF-specific credentials between the UE and the NAF typically requires this as well. Thus, the problem resides in that the conventional GAA and/or GBA mechanisms do not work, i.e. cannot be used for authentication, in case there is no return channel from the user equipment to the network. An example for such a scenario are broadcast networks, e.g. the user equipment being a set-top box (STB; or digibox) for digital video broadcasting. In such a scenario, GAA and/or GBA according to the prior art cannot be used as the UE can neither bootstrap with the BSF nor communicate with the NAF in a bidirectional manner, as is required.
In a contribution to the DVB-H (Digital Video Broadcasting for Handhelds) consortium and the ETSI (European Telecommunication Standards Institute), Vodafone presented a proposal for an interface for a USIM card-based element of the mechanism used to derive keys for service protection. However, this proposal is not suitable to overcome the problem described above and the related drawbacks.
Thus, a solution to the above problem and drawbacks is needed for providing security in such scenarios which are becoming more and more important for future use.